Summary Pane
The
Summary pane 
displays a one-line summary of every frame
in a capture buffer or file, including frame number, timestamp, length
and basic protocol information. The protocol information included for
each frame depends on the protocol selected in the summary layer box (located
directly below the main toolbar).
On a two-channel circuit, the background color of the one-line summary indicates whether the frame came from the DTE or the DCE device. Frames with a white background come from the DTE device, frames with a gray background come from the DCE device.
The ComProbe USB Summary pane in displays a one-line summary of every transaction in a capture buffer or file. Whenever there is a transaction it is shown on a single line instead of showing the separate messages that comprise the transaction. The Msg column in that case says “Transaction”.
Each message in a transaction contains a packet identifier (PID). All of the PIDs in a transaction are shown in the transaction line.
All "IN" transactions (i.e. transactions that contain an IN token message) are shown with a purple background. All other transactions and all non-transactions are shown with a white background. "IN" transactions have special coloring because that is the only place where the primary data flow is from a device to the Host.
The protocol information included for each frame depends on the protocol selected in the summary layer box (located directly below the main toolbar).
Frame numbers in red indicate errors, either physical (byte-level) or frame errors. If the error is a frame error in the displayed protocol layer, the bytes where the error occurred is displayed in red. The Decode Pane gives precise information as to the type of error and where it occurred.
The Summary pane is synchronized with the other panes in this window. Click on a frame in the Summary pane, and the bytes for that frame is highlighted in the Event pane while the Decode pane displays the full decode for that frame. Any other panes which are being viewed are updated accordingly. If you use one pane to select a subset of the frame, then only that subset of the frame is highlighted in the other panes.
Protocol Tabs
Protocol filter tabs are displayed in the Frame Display above the Summary pane.
-
These tabs are arranged in separate color-coded groups. These groups and their colors are General (white), Classic Bluetooth (blue), Bluetooth low energy (green), 802.11 (orange), USB (purple), and SD (brown). The General group applies to all technologies. The other groups are technology-specific.
Example Protocol Tags
- Clicking on a protocol filter tab in the General group filters in all packets containing that protocol regardless of each packet’s technology.
- Clicking on a protocol filter tab in a technology-specific group filters in all packets containing that protocol on that technology.
- A protocol filter tab appears in the General group only if the protocol occurs in more than one of the technology-specific tab groups. For example, if L2CAP occurs in both Classic Bluetooth and Bluetooth low energy , there will be L2CAP tabs in the General group, the Classic Bluetooth group, and the Bluetooth low energy group.
Select the Unfiltered tab to display all packets.
There are several special tabs that appear in the Summary pane when certain conditions are met. These tabs appear only in the General group and apply to all technologies. The tabs are:
- Bookmarks appear when a bookmark is first seen.
- Errors appear when an error is first seen. An error is a physical error in a data byte or an error in the protocol decode.
- Info appears when a frame containing an Information field is first seen.
The tabs disappear when the capture buffer is cleared during live capture or when decoders are reloaded, even if one of the tabs is currently selected. They subsequently reappear as the corresponding events are detected.
The tabs disappear when the capture buffer is cleared during live capture or when decoders are reloaded, even if one of the tabs is currently selected. They subsequently reappear as the corresponding events are detected.
Use the navigation icons, keyboard or mouse to move through
the frames. The icons 
and 
move you to the
first and last frames in the buffer, respectively. Use the Go
To icon 
to move to a specific frame number.
Placing the mouse pointer on a summary pane header with truncated text displays a tooltip showing the full header text.
Summary pane (right) with Tooltip on Column 5 (Tran ID)
Sides in Bluetooth low energy
A Bluetooth low energy data connection consists of connection events, which are a series of transmissions on the same channel. In each connection event the master transmits first, then the slave, and then the devices take turns until the connection event is finished.
When the data connection is encrypted and the packets are successfully decrypted, the sniffer can determine exactly who sent which packet (only non-empty, encrypted packets – empty packets are never encrypted). These packets are labeled either ‘M’ for master or ‘S’ for slave.
When the data connection is unencrypted or when encrypted packets are not successfully decrypted by the sniffer, the sniffer cannot distinguish the two devices’ (master and slave) packets by their content, just by the packet timing. In those cases we label each device as side ‘1’ or ‘2’, not as master or slave. In each connection event, packets sent by the device which transmitted first in the connection event are labeled ‘1’, and packets sent by the device which transmitted second are labeled ‘2’.
If no packets in the connection event are missed by the sniffer, the device labeled ‘1’ is the master and the device labeled ‘2’ is the slave. However, if we do not capture the very first packet in a connection event (i.e. the packet sent by the master) but do capture the packet sent by the slave, we label the slave as side ‘1’ since it is the first device we heard in the connection event. Because there is potential clock drift since the last connection event, we cannot use the absolute timing to correct this error; there would still be cases where we get it wrong. Therefore we always assign ‘1’ to the first packet in a connection event. So even though it is rare, there are connection events where packets sent by the slave device are labeled ‘1’ and packets sent by the master are labeled ‘2’.
Finally, in a noisy environment it is also possible that the sniffer does not capture packets in the middle of a connection event. If this occurs and the sniffer cannot determine the side for the remaining packets in that connection event, the side is labeled ‘U’ for “unknown”.